Emit identifiable error frames on the direct-write path (MJ-16)#89
Merged
jonasniesner merged 1 commit intoJul 6, 2026
Merged
Conversation
MJ-16: The compressed direct-write path emitted generic {0xFF, 0xFF} error
frames, so a failing command was unidentifiable. The published spec says error
frames are 0xFF followed by the command code ({0xFF, cmd}). Make the firmware
conform by setting the second byte to the failing command's low byte, matching
the existing {0xFF, 0x72} gray4 END frame.
Sites (src/display_service.cpp):
- handleDirectWriteCompressedData length-overflow guard -> {0xFF, 0x71} (DATA)
- handleDirectWriteCompressedData zlib-stream failure -> {0xFF, 0x71} (DATA)
- handleDirectWriteStart decompressed-size mismatch -> {0xFF, 0x70} (START)
- handleDirectWriteStart initial zlib-stream failure -> {0xFF, 0x70} (START)
- handlePartialWriteStart zero logical-size guard -> {0xFF, 0x76} (PARTIAL START)
- handleDirectWriteEnd compressed final-flush failure -> {0xFF, 0x72} (END)
Backward-compatible with updated clients: py-opendisplay PR #120's
is_compressed_failure_frame() accepts both {0xFF, 0xFF} and {0xFF, 0x70} for the
compressed-START fallback, and the website direct-write handler (PR OpenDisplay#28) treats
any leading-0xFF frame as an error.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012g2e8mr132vcizx92WsgiR
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The compressed direct-write path emitted generic
{0xFF, 0xFF}error frames, making the failing command unidentifiable. The published spec says error frames are0xFFfollowed by the command code ({0xFF, cmd}). This makes the firmware conform: the second byte now carries the failing command's low byte, so the frame identifies which command failed. This matches the already-present{0xFF, 0x72}gray4-END frame in the same file.Sites changed (
src/display_service.cpp)handleDirectWriteCompressedData{0xFF, 0x71}handleDirectWriteCompressedData{0xFF, 0x71}handleDirectWriteStart{0xFF, 0x70}handleDirectWriteStart{0xFF, 0x70}handlePartialWriteStart{0xFF, 0x76}handleDirectWriteEnd{0xFF, 0x72}Frames stay 2 bytes; only the second byte changed. No
{0xFF, 0xFF}emissions remain in the file.Backward compatibility
Pairs with py-opendisplay PR #120. Its
is_compressed_failure_frame()accepts both{0xFF, 0xFF}and the spec-conformant{0xFF, 0x70}, so the compressed-START fallback keeps working regardless of which frame the firmware sends. The DATA/END/partial frames were never valid ACKs, so updated clients raise the same typed protocol error as before — now with the command identified. The website direct-write handler (PR #28) treats any leading-0xFFframe as an error.Testing
pio run -e nrf52840custom— SUCCESSpio run -e esp32-c3-N4— SUCCESS🤖 Generated with Claude Code
https://claude.ai/code/session_012g2e8mr132vcizx92WsgiR